Conditional access systems (CAS) protect high value content from unauthorized viewing by encrypting the content stream prior to distribution. Access control to the content is enforced by providing the content decryption keys only to authorized devices. Traditionally, the association of a device to a subscriber has been static, meaning that following completion of subscription contracts with a service provider (SP), the SP provides a device (e.g., a set top box) to the subscriber, which may be installed at the subscriber's permanent location. In this way a permanent subscriber-device relationship (binding) can be configured at the service provider data bases and CAS servers, distributor head end and streaming equipments. During this configuration, a device's identity and credentials would be added to the list of devices authorized to receive content decryption keys.
With advances in mobile computing and networking technologies as well as new trends in consumer behavior, new demands are being placed on the content supply chain: content needs to be available from any source, including traditional distributor networks, the Internet and wireless networks. The business models interacting with the consumer are also expanding: A subscriber with a business contract with a service provider (SP) may wish to view the subscribed content on devices other than her home set top (e.g. a mobile phone), or at locations other than her home, e.g. on a set top in a hotel or a friend's house. The subscriber may also wish to view content on demand, either from her service provider catalogue or from a 3rd party Internet sources.
Support for the aforementioned supply chain and business models go beyond the traditional mechanisms in which a manufacturer simply provides a database of device identifier and keys to the operator and the operator then binds the device identity to the subscriber who received the device. If the subscriber has acquired the device through retail channels, the SP may have no a priori knowledge of the device or the fact that the device will be used by this particular subscriber. Furthermore, with the growing list of types of devices that can render content, the SP may have no information about the device's fitness (e.g., robustness properties and other capabilities) for rendering content on the device without risking the content owner's business interest. Another issue that complicates the scenario is that each of these devices may obtain network connectivity/packet transport through a different access technology or a separate network provider (NP) and it is desirable for the details of network connectivity to be transparent to the SP authorization and CAS processes.
Given that the business contract is typically between a subscriber and a SP, the authorization to view content needs to be enforced by a trust relationship that is built based on subscriber profile (subscriber identity, credentials, and subscription profile). However, since the content needs to be delivered to and decrypted by the device, the distribution of content and content decryption keys needs to take into account the device characteristics such as device identity, private keys, and robustness profile (i.e., the ability of a device to protect valued assets such as content and keys as required by owners and distributors).
The above requirements place new demands on SP security procedures: The SP needs to not only authorize the subscriber based on the underlying business model and subscription profile, but also ensure that the content is consumed (or equivalently, ensure that content decryption keys are obtained) only on a device that is properly associated to that authorized subscriber for the particular content that is to be consumed and only for the period of time during which the authorization is provided. The SP must also ensure that such transport is not threatened by passive eavesdropping of the keys, or redirection of the keys to unintended devices. This means that the SP not only needs to authenticate the device that the subscriber is currently using, but also ensure that an authorized subscriber is actively present at the device and is not being impersonated by service/content thieves.
From the Digital Rights Management (DRM) perspective, it is also important for the SP to know the level of robustness with which the device can store and execute sensitive material related to the distributed content so the SP can avoid the risk of piracy.
Another design consideration is that current subscriber authentication is often based on cryptographically weak methods and credentials, such as passwords and four-digit personal identification number (PINs). Such authentication credentials and methods, if not adequately protected, may not only jeopardize the consumer's privacy (e.g., location, identity) but also lack non-repudiation mechanisms that leave both the consumer and SP vulnerable to service theft. For instance, a system that actively involves the subscriber in the authorization process denies the subscriber the ability to dispute a previously consumed service (e.g. a movie watched) while at the same time protecting the consumers from having to pay for content consumed by others. An active and dynamic binding of subscriber and device credentials could provide indisputable evidence that the subscriber participated in the transaction. Thus the overall mechanism should be such that subscriber credentials are protected from tampering and eavesdropping.
It may also be desirable for the security procedures to provide the option of fast re-authorizations, so that a subscriber does not have to go through the lengthy authentication and binding process after having paused or interrupted the connection. For instance, subscribers should be able to access their services on a device in a hotel room with little delay during the entire period of 24 hours after having paid for 24 hours of service.
Finally, in Internet-type architectures, authorization and authentication is typically performed by an authentication and authorization (AAA) server, which has nothing to do with the actual content distribution. The content distribution and rights management are typically performed by DRM/CAS systems that can be independent of the SP authorization system and which are often provided by third party suppliers. Thus, the result of an authentication and binding process as described above needs to be communicated to a CAS. Such interfaces between the AAA server and CAS systems have not been currently available.
EAP-TTLSv0, (Extensible Authentication Protocol) which is described in RFC5281, provides a method that allows a client to first establish a tunnel with a server (typically based on server-only authentication) and then authenticate itself using weak authentication mechanisms/credentials which are delivered to the server through the tunnel (this is called inner authentication). EAP-TTLS also allows clients to perform multiple inner authentications using different sets of credentials. EAP-TTLSv0 does not bind the tunnel protocol to the inner authentication method(s), nor does it bind the multiple inner authentications to each other. In addition, multiple inner authentications can only authenticate the same entity, meaning that the client is from a cryptographic point of view one and the same entity. EAP-TTLSv0 provides session resumption using the native transport layer security (TLS) mechanism with unprotected session IDs. Due to its lack of method bindings and single client nature, EAP-TTLS does not provide any adequate subscriber-device binding.
PEAPv0 and EAP-FAST provide similar tunneling mechanisms. Both methods further provide a cryptographic binding between the tunnel and the inner authentication(s) by creating dependencies in the derivation of session keys. In particular, keys from tunnel and inner authentications are combined to derive MAC keys used in the remainder of the session and to generate the Master Session Key (MSK). Similar to EAP-TTLSv0, PEAPv0 and EAP-FAST both provide session resumption per TLS abbreviated handshake. In addition, EAP-FAST supports session resumption using protected access credentials in the form of tokens. Still none of PEAPv0 and EAP-FAST can bind the authentications of two different entities to a tunnel and, thus, cannot provide an adequate subscriber-device binding.
In 3GPP general bootstrapping architecture (GBA) [3GPP TS 33.220], integration of previous authentication to current security establishment exchanges is done by the authentication server (HSS) sending the AKA Authentication Vectors (AVs) to the BSF (bootstrapping function), which extracts AUTN and RAND and sends them to the UE, which after verifying the AUTN, calculates the RES and sends it back to the BSF and after that they establish a Ks=(CK∥IK).
This method is based on use of SIM cards which use symmetric encryption and not certificates or TLS. Solutions where states resulting from a previous authentication can be included in TLS exchanges do not exist.
Kerberos is another area where an authentication server initially authenticates a client and issues tickets for the client to deal with other servers. The downside is that Kerberos ticket granting mechanism relies on specific Kerberos protocol and the client needs to prior to interacting with each new server go back to the initial ticket issuing server and get a new ticket for the new server. The idea described here eliminates this step while not requiring any specific protocol interactions with the TLS server.
IETF RFC4279 proposes mechanisms for use of pre-shared keys (PSK) with TLS and even uses PSK to build a premaster secret. However, this RFC defines use of pre-shared keys instead of public key certificates for environments where either the client has limited computation capacity or certificates are not available because PKI is not available. The usage scenario of RFC4279 is distinguished from the methods described herein, because while RFC4279 removes the certificate and certificate request payloads for the exchange. In contrast, in the embodiments described herein, device and server both have capability to use certificates and do actually use the certificates to establish the TLS but the security policy dictates that the authorization profiles of the device and subscriber must be checked by another authority before allowing the client to establish the TLS with the current server. Also the RFC proposes changes to the main line TLS (RFC 4346) stack, since it introduces new attributes (e.g. PSK-identity) that use pre-shared keys instead.
None of the previously mentioned authentication and authorization methods treats the device and the subscriber as two separate entities. Rather, in these methods the client is the same entity who performs multiple layers of authentications using different credentials. They do not take into account the situation where a device can have its own identity/certificate while the user (e.g., a subscriber) is a human with a different identity/credential pair. That is, known techniques do not take address those cases or solve the problem in which the device and subscriber may have a physically, logically and cryptographically loose existence.